This is redundant now and can be removed. Same applies to other places in the file.

Super minor nit but I tend to find this kind of thing is more easy to understand when implemented as:

const paramCounts = Object.fromEntries(
  Object
    .entries(Object.groupBy(feeds, feed => feed.updateParameters))
    .map(([updateParameters, feeds]) => [updateParameters, feeds.length])
)

I will also typically create a mapValues helper (which really should be in the ES standard IMO and probably will be eventually) which I use all the time and makes the code more concise:

const paramCounts = mapValues(
  Object.groupBy(feeds, feed => feed.updateParameters)),
  feeds => feeds.length
)

For some reason, reduce seems to be a hard operation for a lot of folks to easily grok so I've started to move away from using it except in very specific scenarios. Here is a decent writeup for an eslint rule that I use nowadays that has some links to some threads on the topic.

I really dislike this kind of thing, it's very brittle (i.e. it's a pain to ensure every change is tested across device sizes and it's easy to do something that changes the calculations and not know it breaks the UI) and it's very easy to run into render issues on different platforms where size calculations have slight differences.

It also feels unnecessarily complex for what you're looking to accomplish.

In this case, what I'd suggest doing is just adding the max-height css property to the table

This seems a bit strange to me, is there any reason why params here needs to be free text with html embedded? This is not coming from a CMS or any external source, so there shouldn't be any reason to pass around html as strings. I'd suggest changing the format of updateParameters -- either pass around jsx fragments, or better yet, since it looks like the only difference in the entries is the heartbeat length & the deviation, just make updateParameters something like { heartbeatLength: number, deviation: number }

Personally, I'm not a fan of this. I know the repetition is obnoxious, but when I'm looking up data, I'd much rather see repetition, but to have the value I'm looking for right where I'm looking, than to see "same as above" and then have to go cross reference another row.

My suggestion would be to just use the isFirstInGroup style for every entry.

If that's the case, then shouldn't we keep these update parameters in the top line?

But if we do that, then the experience wouldn't be consistent between all the table.

I'm not sure I follow but from the screenshot I don't see any reason to get rid of the top line or the green/red dots, it's a helpful way to highlight the data that differs from baseline.